A database is a collection of related data items. To perform various tasks, users access data items stored in the database via transactions. These user accesses need to be controlled to ensure data consistency.
A database management system (DBMS) supports transactions to access the data items stored in the database. To get a consistent view of the data items, the transaction acquires locks on the data items before accessing them. The transaction may release these locks when it no longer needs access permissions to the data item. By default, all locks that the transaction owns are released when the transaction completes. Thus it can be inferred that every lock that the transaction acquires has an associated life-span. This life-span is the time elapsed between when the lock is acquired and when the lock is released. This lock life-span is commonly referred to as a lock duration. The lock duration is typically shorter than the life span of the lock acquiring transaction. A lock manager (LM) processes locking and unlocking requests by transactions. The LM should also support the ability to release locks in a given group before the transaction finishes.
Transactions have an additional property called isolation. Generally, DBMSs support serializable, cursor stable, read committed, dirty read, etc., isolation levels. For most non serializable isolation levels, locks may be released on data items before the transaction finishes. One such example is a read committed isolation level. According to the consistency semantics of this isolation level, the most recently committed value of the given data item should be read by the accessing transaction. One implication of this is that the transaction may request a lock on a data item, read the data item, and then release the lock on the data item, and this may be repeated as many times as desired, where each read of the same data item may potentially return a different value. Such a transaction may need to group locks and release the group locks in one call to the LM, instead of releasing all such locks individually.
Commercially available DBMSs support a few lock durations. Each duration has a distinct name and predefined semantics. For example, instant, short, medium and long lock durations are used in many commercially available DBMSs. The duration of a lock is not determined by the LM, but by the transaction that requests the lock. A transaction may, based on its isolation level, choose different durations for the same data item. If the transaction is executing under serializable isolation, then the lock durations are trivially from the time acquired to the end of the transaction. In this case, all locks for a transaction are released when the transaction execution is complete.
However, for weaker isolations (cursor stability, read-committed), lock durations play a very important role. Transactions may request release for some locks before transactions are complete. Such early release of locks is necessary to promote transaction concurrency. Reducing lock duration reduces access conflicts. For example, a transaction may request locks that are to be released early in the medium duration. When the transaction determines that access is no longer needed to any data item in that set, it may request the LM to release all medium duration locks.
However, there is currently no meaningful way to define and manage a potentially unlimited number of groups which a transaction may want to classify a given lock. Managing these groups with a few a priori meaningful lock durations will necessitate a separate queue manager that will need to note all classifications. This would be cumbersome and complicated. Providing only a few lock durations may not be suitable to effectively manipulate lock usage for complex non serializable transactions.
The present invention addresses this and other problems associated with the prior art.